在我們這個月以來花了很多時間解構敏捷之後，會發現其重互動、低流程，且在每個站立會議中，每個人都有發言的機會，在這樣的過程中理應資訊更加同步與透明。所以如果你的團隊正在實施敏捷，不妨回想一下，你的團隊中，大家所知道的資訊是否質量差不多，彼此都知道彼此在進行什麼。

而這樣的透明度很重要，除了站立會議外，敏捷當中也有很多元素有助於減低資訊的不對稱，但這前提是必須把這框架的事確確實實的仔細做好。
例如**「開卡」這件事，從需求端，如果簡單寫個功能的大標跟簡短的描述，會存在太大的解釋空間，可能被指定到的開發成員還需要自行想像，最後上線的成品又跟需求方不一致；而在實作端，也建議把一些開發細節做個紀錄，不只是要給別人看，而有一部分是為了自己而寫，當你身上掛很多任務卡片時，或這張卡並沒有要馬上動工時，事後再回來看就不用憑藉自己的記憶力，而是有當初紀錄的資訊可以參照。任何針對任務卡片的口頭討論，也建議可以落到卡片上，像是 Trello, Jira 的留言**功能就可以善用，上面的時間戳記更可以讓事後追蹤更簡單。

真的有那麼嚴重嗎？如果團隊不透明會發生什麼問題？

1. 各做各的事

因為團隊成員都不知道彼此在做什麼，甚至任務間有連貫都沒察覺，因此各行其是，到要合版時才發現合不起來，或兩個人寫的邏輯互相衝突，那該叫誰重寫呢？

2. 前無古人、後無來者

當有一個成員把許多資訊隱藏起來，或沒有同步其實作的資訊，當這位成員離開後，就會發現原來這包 code 根本沒人接得起來，或要接受的時間成本很高，而這時候通常都為時已晚了。或是可以檢視「公車指數」，這個故事是這樣：假設有一天，你接到電話說，團隊一起出去吃飯，有人被撞公車撞到了。如果是一個人被撞到，這個人剛好是團隊的超級核心，對專案有巨大影響，公車指數就是【1】。如果是兩個人同時被撞到，才會對產生巨大影響，那公車指數就是【2】。（可以參考這篇文章：https://agile.ithome.com.tw/2022/news-page/271）

3. 信任感低落

資訊不對稱長期累積下來的各種事故最終導致的便是團隊成員間的不信任，空氣間彷彿瀰漫著一股這樣的氣氛 “一定有什麼事瞞著我” “那我也不想要透露我的資訊” 。

總之，如果你的團隊正在運用敏捷框架，那恭喜你，可能在一個相對透明的環境裡，但如果你們是一個敏捷團隊但又有很多秘密的話，那就真的要好好檢視內部究竟發生什麼問題，或有什麼互動上的 issue 需要被解決。